projectsparkfandomcom_fr-20200214-history
Tuiles qui se réinitialisent
Vous devriez déjà être au courant maintenant que les cerveaux de Project Spark s'exécutent 30 fois par seconde, en partant du début et en parcourant le kode jusqu'au bout à chaque tic : c'est ce qui fournit la boucle principale du jeu (ou game loop en anglais). Mais comme tout ce qui se passe dans Project Spark existe au sein de cette boucle du jeu, le langage lui-même est conçu pour s'en servir. Ainsi, plusieurs tuiles permettent de faire en sorte que le kode ne s'exécute pas immédiatement, mais peut-être un peu de temps après qu'il soit appelé pour la première fois. Regardons comment quelques-unes de ces tuiles fonctionnent. Attardons-nous tout d'abord sur la tuile maintenant. Cette tuile regarde si une condition était vraie, mais est maintenant fausse. Une telle tuile ne pourra jamais se déclencher au premier tic qu'elle est lue. maintenant vérifie si la condition était vraie au tic précédent, mais ne l'est plus maintenant. Pour que cela arrive, il faut au moins deux tics, premièrement un tic où la condition est vraie, puis deuxièmement un tic où la condition est devenue fausse. Traduction et amélioration du texte anglais original à venir First let's look at the longer tile. This tile works by checking to see when a condition is no longer true, and when it is no longer true, executing its rules. However, the longer tile can never trigger on the first frame it is run. "No longer" implies that the condition used to be true, but just switched to false. For that to happen, at least two frames are needed, first a frame where the condition is true, and second a frame where the condition is false. There can be any number of frames where the condition is true, but as soon as the condition becomes false, the rules will be executed. Another tile that works over time is the timer tile. The first time it is evaluated, it stores the current time and uses that as its starting time. Then, on each subsequent frame that the timer tile is evaluated, it checks to see if enough time has passed since the start time, if so, the rule is executed. For most of these tiles that happen over time, things work just fine when they are being evaluated, but something interesting happens when the rule isn't evaluated for even a single frame. When not evaluated, these tiles will often reset. Let's look at the timer tile. If the tile is ever not evaluated when running through the brain it is in, the start time of the timer will be lost, and the next time the timer is evaluated, it will start over, measuring its start time as the first frame that it was evaluated once again. This is a common pattern in brains, and that's why it is important to understand before going too much deeper, because it gives a different perspective of what the language is doing. The tiles which are prone to resetting are, I believe, all in the Timing and Logic folder in the tile picker, and they all are used on the When side of the brain. Whenever a tile needs to store information for a later frame, it is prone to resetting, and the reset will likely make it lose whatever information it has stored. In the case of the longer tile, the state that it stores is that it got at least one frame where its condition was true. If reset, that information is lost and it will need another frame where its condition is true before it can trigger when its condition switches to false. This is an important concept, so will be expanded upon in the Timing and Logic section. = À lire ensuite = Timing et logique [[Apprentissage du Kode|'< Retour à l'Apprentissage du Kode']] en:Tiles_That_Reset Catégorie:Kode